COMMENT ⊗   VALID 00007 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	rg
C00008 00003	alice
C00010 00004	griss
C00011 00005	peter
C00013 00006	dave
C00015 00007	to do
C00016 ENDMK
C⊗;
rg
p 2. bottom:
	re: time sharing; para 3 → reluctance; para 4 → enthusiasm
	somewhat contradictory

p 3. top: 
	Work there pointed the way as to how one might ...
			↓
	Work there suggested how one might ...

p 3. bottom:
	after "fully parenthesized list structure notation"...
	mention why this "program≡data" is a win.

p 3. list of desirable features is good: it should be embedded in the
	the forehead of every machine architect!

p2-3 too many  "in additions" (3)   in fact "in addition"  happens a lot in the
		paper

general comment: intro needs more punch. Author doesn't hit his stride
page 4;then he takes off!


p8; bottom-11;  flush "tacked on".


p9; para 4 (about paging) this seems out of place in a section called lisp as
	a systems language; doesn't it belong in the previous section
	on hardware implementation?
 ...and  p9; top+15;   "guts"? tsk,tsk

p10; last line before "high level:": sentence is incomplete (missing a "since")

p10; two line above previous "speed up" → "speed"


p14; extended number format (32 mantissa, 11 exponent) isn't obvious

p19; line 2 "; this means that the programmer has to ... ." why advertise
	this? this is only important to the LM hacker.
 	GENERAL MAXIM: don't  bring up negative points for the  article reader. 
			"EVERYTHING IS WUNERFUL"

P22-23; CLOSURE VS. FUNCTION: perhaps note that (function <fn>) "closes" ALL free
variables in <fn>, even those free within functions called by <fn>.

pp23-24; i think sandewall proposed this closure solution in early '70s.

p24; bottom-3 Lisp machine → Lisp Machine

p30; "A further large step ..."; hum, this seems to imply that this was an
	MIT invention; TVEDIT on PDP-1 was an E-EMACS type editor written
	in 1965 at Stanford and used exclusively until demise of pdp-1.

p30; bottom-7 "...takes place incrementally and instant..."
	 			↓
		" is incremental and instantaneous"

p30 bottom-2    comming → coming

p31 top +10   gendre → gender? (probably genre) actually the "species of this
		genre(der)" remark is could be reworded.

p31 para 3, line 4: recepiant → recipient
p31 para 4, line 1: recepiant → recipient

p31 para 4, line 6: acessed → accessed

p32 para 2, line 10 ina → in a

p34 para 2, line 9  "had to win .."  slang

p34 bottom-4  "going the 32 bit route" needs rewording

p34 bottom-2  "another similar sort of ..""
			↓
		"A similar ..."

p34 bottom line  deutch → deutsch  (similarly in bibliography)

p35 top+2   "...this was probably a ..."
			↓
            "...this was  a ..."      ?   or remove the following "probably"


???LISP MACROS   and LM formattting stuff ????

GENERAL COMMENTS:
	There is clearly no doubt about the content and organization of this
paper. It is first rate.
	Some sections need to be tightened up --too informal, with slang terms
here and there. I've already suggested that a more forceful introduction
might be given; as a general rule i'd like to see phrases like "we attempted...",
"we probably should have ...", or "unfortunately the user .." ALL thrown out!
Its a damn good machine so why give the casual reader reason to believe that
it has dark corners?  
	If remarks like that belong anywhere they should be in the
"Some Design Decisions and Lessons" section, but don't put them in the body
of the paper, giving a reader the opportunity to say "what a krok!" before
he has seem the whole design (then he CAN'T say it).

alice

p1, para 2, line 15 Human fctors →  Human factors

p2, para 1, line 7: band → baud

p4↔p7; "segment" isn't defined until page 7. move up definition

p4↔p10;  the parenthetical remark (p10) about slot = 32 bits should
	be moved up to discussion of stack (p4). 

p7  para 1; details about greenblatt may not be needed since greenblatt
	is also represented in this issue.

p7 bottom-17 descipline → discipline

p7 bottom-8 ".. are stored in a data space 
		separate from the atoms themselves. Another segment is reserved
		for value cells, and ..."
			↓
            " are stored in a separate segment reserved for values cells, and ..."

p10  first line of LOCAL: vaiable →variable

p10 line 2 of LIT: " 22 0r 32" → 22 or 32

p14 CALL opcode "call function by name..." → "call function using name"
	dont want non-lisp-ers to think "call by name"

GENERAL COMMENTS:    A very pleasant paper!  Similar question to other papers:
	would readers be helped by a diagram showing  stack behavior? dunno.

griss

p2;  hum....use of "P-code" confusing to Pascal-ites? (...they're
	easily confused.)

p 12; make it clear what RLISP is.

p36-38;  flush overlap with Deutsch, Hartley, and Greenblatt

p40 top+5 then → than

p43 conclusion+13  lisp like → lisp-like

p48-51  flush or condense if the paper is too long



GENERAL COMMENTS
A very long paper, with a very matter-of-fact style.
Peter's is long, but much more "lively".
peter

p51; ref 9 Hewlitt→Hewlett
     ref 10  how about the CACM reference on "two-level storage ..." instead

p20  data formats would be easier for the reader if a small diagram
	was used.

p22-25  instruction formats can be sampled only, rather than exhaustively
	cataloged if space is a problem
p34-37 similar remark to previous; (perhaps these tables could be combined
	in an appendix)

p27 "... we believed that deep competitive with shallow in micro code..."
	we don't find  the result of this conjecture until much later; is
	that good? upon reading that i went skimming through the rest of the
	paper looking for the conclusion.  But section 5.4 was unsatisfying:
	p39 top "we evaluated seven diffferent strategies..." number seven,  
	shallow binding, a formula is given, but no conclusions. From
	section 5.4,  the conculsion of section 6.6 certainly follows: "the
	deep vs. shallow binding question is still open."

p29 para 2, line 4   structurebeing → structure being

p31 bottom-3 is "[]" after "bitblt" necessary here?



GENERAL COMMENTS
A long, but information-filled  paper; good style. it is difficult to see where
to shorten it.

dave

i assume that ieee will have a copy editor run through these for style

my major  concern  with  these  papers is  that  the  non-lisp  readership
probably won't understand  what these  papers represent.  that's the  same
problem i will run into in the  august byte. at least there the  technical
is much less demanding.

perhaps an intro should mention an introduction for lisp novices; i  would
(blush, blush)  suggest  the  august  byte  1979,  with  reference  to  my
editorial in march 1979 byte.

there is an incredible amount of detail  in these papers; i don't know  if
diagrams would help  any or whether  arrows and boxes  and ... would  only
make things worse.

this will be a CLASSIC issue!!!!   all these papers are first-rate (it  is
amusing to see the totally different styles of presentation, however)

***glossary***?


one refernece seems to be universally missing: i think the first PUBLISHED
"closure" solution to the funarg problem was erik sandewall in "a proposed
solution to the FUNARG problem", Uppsala  report #29, Nov 1970.  The  idea
may have been around long before that.
to do

ask alice and griss (ach) for compilrs, code, and associated crap for 
their systems